1. Field of the Invention
This invention generally relates to transaction processing systems and more particularly relates to transaction processing systems capable of processing global transactions and the processing of multiple service requests within a global transaction by a single instance of a server application program.
2. General Background
Advances in hardware and software technology, in combination with new computing models, are expanding the possible functionality for On-line Transaction Processing (OLTP) application software.
On-line Transaction Processing (OLTP) is a style of data processing in which users at terminals or workstations send messages to application programs which update databases in real time. This is in contrast to batch or queued processing of transactions where the transactions are processed at a later time. An example of an OLTP application is an airline reservation system.
A transaction may be thought of as a set of actions performed by a transaction processing system wherein the actions together exhibit the properties of Atomicity, Consistency, Isolation, and Durability (ACID). The following definitions are given in Transaction Processing: Concepts and Techniques by Jim Gray and Andrea's Reuter, Morgan Kaufmann Publishers, Inc., 1993, p. 6:
Atomicity. A transaction's changes to the state are atomic; either all happen or none happen. These changes include database changes, messages, and actions on transducers. PA0 Consistency. A transaction is a correct transformation of the state. The actions taken as a group do not violate any of the integrity constraints associated with the state. This requires that the transaction be a correct program. PA0 Isolation. Even though transactions execute concurrently, it appears to each transaction, T, that other transactions execute either before T or after T, but not both. PA0 Durability. Once a transaction completes successfully, (commits), its changes to the state survive system failures.
To maintain the properties identified above, at the beginning of processing a transaction, a transaction processing application program invokes a Begin-Transaction function to indicate processing of a transaction has begun. This operation is typically logged to an audit file to demarcate the operations associated with a particular transaction. Following the Begin-Transaction function, the other functions associated with the application defined transaction are performed and are also logged to an audit file. If all operations associated with a transaction complete successfully, a Commit function is invoked to make permanent any state changes that have occurred as a result of the transaction. The Commit operation is logged to the audit file to indicate that all operations have completed successfully. If an error occurs during processing of the transaction and a Commit operation is not performed, a Rollback function is invoked to undo the effects of the operations performed in processing the transaction.
The Client/Server computing model provides a framework in which the functionality of transaction processing applications may be expanded. Under the traditional mainframe transaction processing application model, the user interface, application control, and data management control all execute on a single data processing system. Generally, the Client/Server computing model involves a Client application program submitting service requests to a Server application program, and the Server application program processing the requests and returning responses to the Client. Thus, a Client/Server environment has the user interface, application control, and data management control distributed among two or more data processing systems. The Server application programs must contain data management components and may also provide some functions of other components.
One widely used scheme for classifying Client/Server type systems is according to how they distribute user interface, application, and data management components between the Client and Server data processing systems. Two examples include the remote presentation type Client/Server application and the distributed data processing Client/Server application. In a remote presentation application, all the user interface functionality resides on the Client system and all other functionality resides on the Server system.
For a distributed data processing Client/Server system, the data management functionality is divided between the Client and Server systems. All other functionality is placed on the Client system. The distributed data processing Client/Server model allows databases to be split among multiple systems and fosters development of distributed transaction processing applications.
Transaction processing in a Client/Server environment may be either non-global or global. In a non-global client/server transaction, the same work takes place as in a traditional transaction, but the work is distributed in a Client/Server manner. For example, a travel agent may request an airline reservation via a workstation Client application program that has a graphical user interface. The Client application program communicates with a Server application program that manages the reservation database. The Server application program updates the database, commits or aborts its own work, and returns information to the Client application program, which notifies the travel agent.
A global transaction consists of multiple, coordinated database updates, possibly occurring on different computers. Global transactions are used when it is important that all databases are synchronized so that either all updates are made or none are made. Continuing with the previous example, the travel agent may also need to reserve a rental car and hotel room. The customer who is traveling wants to make sure that all reservations are coordinated; if a flight is unavailable, the hotel and car reservations are not needed. For the purpose of illustrating a global transaction, the airline, car, and hotel databases are on different transaction processing systems.
The global transaction begins when the travel agent requests the reservation from a workstation Client application program with a graphical user interface. The Client program contacts three Server application programs on different transaction processing systems. One Server program books a flight, another reserves a car, and the third makes a hotel reservation. Each of the Server application programs updates its respective database. The transactions processed by each of the Server application programs may be referred to as a subordinate transactions of the global transaction. A global transaction manager coordinates the updates to the three databases, and a subordinate transaction manager on each of the individual transaction processing systems coordinates locally with the Server application programs. The Server application programs return information to the Client application program.
A major advantage of global transaction processing is that tasks that were once processed individually are processed as a group, the group of tasks being the global transaction. The database updates are made on an all or nothing basis. For example, if an airline seat is not available, the hotel and car reservations are not made. Thus, with a global transaction, tasks that were once performed independently may be coordinated and automated.
As with non-global transactions, global transactions must possess the ACID properties. In order to preserve the ACID properties for a global transaction, the commit processing is modified to a two-phase commit procedure. Under a two-phase commit, a global transaction manager first requests that each of the subordinate transaction managers prepares to commit their updates to the respective databases. If all the local transaction managers respond that they are prepared to commit, the global transaction manager sends a commit request to the local transaction managers. Thus the two parts of the two-phase commit are prepare to commit the database updates and commit the database updates.
As part of a global transaction, a Client application program may generate multiple service requests to be processed by the same Server application program logic. If the Client application program and Server application program are resident on separate data processing systems, there are numerous layers of hardware and software involved in initially sending the multiple service requests and in the corresponding dialogue between the Client application program and Server application program. Communicating through the layers of hardware and software introduces processing overhead for a global transaction.
Where multiple service requests of a global transaction are to be processed by the same Server application program logic, prior art distributed transaction processing systems introduce processing overhead in two ways. First, while the same Server application program logic is capable of processing multiple service requests within a global transaction, a separate instance (or executing process within a data processing system) of the Server application program would be started to process each of the service requests. Processing overhead is introduced because multiple processes must be managed. Furthermore, database locks may not be shared between the separate Server application program instances.
A second way in which processing overhead is introduced is in the mechanism through which messages are sent from and received by the Server application program. Some systems start a separate intermediate communication program instance for each service request that is received. Then through interprocess communication mechanisms, the service request and subsequent communication between the Client application program and the Server application program instance are passed through the associated intermediate communication program instance. This adds processing overhead to the system because of multiple intermediate communication program instances on the system of the Server application program.
Therefore, while a transaction processing system capable of processing global transactions provides great flexibility in the types of applications that may be developed, the communication processing overhead may be a limiting factor if an application has demanding transaction throughput requirements.